The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video content over Internet Protocol (IP) networks. RTP is used to implement many different types of business applications such as digital telephony, video conferencing, and telepresence. Standards related to RTP can be found in the Internet Society's Request For Comment (RFC) 3550—“RTP: A Transport Protocol for Real-time Applications” and RFC 3551—“RTP Profile For Audio and Video Conferences and Minimal Control”, the entire contents of which are hereby incorporated by reference for all purposes as though fully stated herein.
The packet header of an RTP packet contains a field which identifies the payload type of the media content being transported. In the context of RTP, the payload type defines the type of coder-decoder (codec) necessary to interpret the payload data. Examples of codecs include codecs compatible with encoding standards such as H.264, MPEG-4, etc. RTP supports a range of current multimedia formats and also allows new formats to be supported without revising the RTP standard.
The payload field only has a limited amount of space (7 bits), which can only represent at most 128 different codecs. Consequently RTP defines two distinct ranges for payload identifiers. The first range, referred to as the static range, covers payload identifiers 0-95. The static range is generally reserved for the most common types of encodings and remains constant regardless of the context in which RTP is used. The second range, referred to as the dynamic range, covers payload identifiers 96-127. Payload identifiers within the dynamic range are not mapped by default to any specific codec. Instead, the endpoints agree on a profile, which is a mapping between payload identifiers within the dynamic range and one or more codecs. Thus, when an endpoint receives a RTP packet with a payload identifier within the dynamic range, the endpoint maps the payload identifier to a codec using the profile. As a result, even though the standard for RTP may not define a payload identifier for a particular codec, the endpoints are still able to use the codec by defining their own dynamic mapping. For example, the foregoing approach enables endpoints to use codecs that did not exist at the time that RTP was defined.
The endpoints may use a separate protocol, such as Session Description Protocol (SDP), to facilitate transfer of the profile. The standard related to SDP can be found in RFC 4566—“SDP: Session Description Protocol”, the entire contents of which is hereby incorporated by reference for all purposes as though fully stated herein.
One consequence of having dynamically mapped payload identifiers is that an intermediary networking device, logically located between the endpoints and configured to intercept or monitor traffic between endpoints but which has not participated in the negotiation of a profile that the endpoints previously performed, cannot determine the codecs used for an RTP session merely by examining the RTP header for the payload type. This creates a problem for certain network diagnostic tools that intercept and examine packets from RTP streams in order to provide visibility into the multimedia traffic in the network. Namely, these diagnostic tools are unable to determine the codecs used in a RTP session by passively monitoring RTP packets. Thus, such tools are unable to meaningfully interpret the payload data and fall short of predicting the traffic behaviors and bandwidth requirements imposed by the RTP media streams carried by the network.